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@ The present invention involves a hospital- 
based integrated medical computer system for 
processing medical and patient infonmation and 
for evolving medical knowledge, diagnoses and 
pnDgnoses. It includes at least one processor 
including a memory and a plurality of medical 
data banks connected thereto, and a plurality of 
separate processor hardware modules at least 
indirectly connected to the memory. The mod- 
ules indude a communication module, at least 
one switching module, an administrative mod- 
ule and a knowledge base module. There is also 
hardware, firmware and software in the pro- 
cessor hardware modules to enable the mod- 
ules to perform at least the following functions : 
for the communication module, to control all 
functional processes of the other modules, the 
main memory and the processor, so that they 
effectively communicate with one another ; for 
the switching module{s), to select and switch 
between selected information as it becomes 
relevant to a process of solving a particular 
problem ; for the administrative module, to per- 
form housekeeping functions, including multit- 
asking control with resource allocation, 
real-time multitasking and scheduling of tasks; 
and, for the knowledge base module, to operate 
knowledge processing functions and to store 
information in the medical data banks. In prefer- 
red embodiments, there are general patient 
databases, physician access point units, patient 
access point units, and service facilities. In 
other embodiments, a plurality of processors 
are included with their own memories and mod- 
ules and are linked together to establish a 
proc ssor unit In processor n t embodiments, 
ther may be one or more s parat int grated 
services digital networks dedicated to predeter- 
mined medical related functions. 
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BACKGROUND OF THE INVENTION 

1. Field of the Invent! n 

The present invention relates to architecture for 
an integrated medical computer system and more 
specifically to a system utilizing one or more proces- 
sors having separate modules for predetermined 
functions. Unlike data processing of conventional 
computer systems and unlike call processing switch- 
ing systems, the present invention system is a signif- 
icant Improvement over modern electronic switching 
systems and includes separate modules for commu- 
nication, switching and administration as, well as the 
addition of one or more knowledge modules coupled 
with a plurality of medical data banks. 

2. Information Disclosure Statement 

United States Patent No. 4,899,839 describes a 
method of monitoring a patient's medicine compli- 
ance. It involves weighing a container of medicine to 
determine a starting weight on a scale which is con- 
nected to a computer with a display unit and storing 
the starting weight in the computer followed by re- 
weighing the container of medicine after a predescri- 
bed dosage is consumed to determine a second 
weight. The computer then determines the difference 
between the starting and said second weight to store 
a dosage unit weight The computer is programmed to 
calculate compliance required weights of the contain- 
er for each dosage administration for the prescription 
period of the medicine. The container of medicine is 
reweighed from time to time on the scale to compare 
actual weight with compliance required weight to de- 
termine compliance and the computer visually dis- 
plays the compliance results on the display unit to 
permit compliance monitoring. Optionally, other pa- 
tient characteristics are also monitored and feedback 
is provided. 

United States Patent No. 5,016,172 is also direct- 
ed to patient compliance and a status monitoring sys- 
tem. It involves utilizing an automatic compliance 
monitoring device which stores compliance informa- 
tion and which may be connected to a computer with 
a display unit The compliance monitoring device or 
the computer is programmed to calculate compliance 
requirements of the container e.g. by number of cap 
openings, by dispensing count or by weight informa- 
tion obtained by the automatic compliance monitoring 
device, for each dosage administration for the pre- 
scription period. The automatic compliance monitor- 
ing device is periodically, occasionally, or randomly 
connected to the computer to compare actual usage 
with compliance required to determine compliance re- 
sults on the display unit to permit compliance moni- 
toring on a monitor at a remote location. Optionally, 
other patient characteristics are also monitored and 



feedback is provided. 

While both of the above prior art patents utilize 
computer systems to provide patient monitoring infor- 
mation to a professional via a computer with feedback 
5 capabilities, they are limited by conventional comput- 
er architecture and do not teach or suggest the phys- 
ical modules, integrated medical system processes, 
architecture and capabilities of the present invention 
system. 

10 In conventional processing of data, the central 

processing unit plays the dominant role in executing 
the binary instructions in a pre-defined programmed 
sequence. Data availability and access is made fea- 
sible by the linking and loading functions. The proe- 
ms esses involved in installing executable binary codes 
into the computer in usable form, are compiling, as- 
sembling and linking as well as the actual loading of 
the program and of the data into the core storage area 
of the computer. One process generally (and conve- 

20 niently) forgotten by the computer scientists is the 
higher level language programming of a problem that 
is to be solved. Assuming no errors in these process- 
es, the machine sequentially executes these instruc- 
tions and brings the program to a normal termination 

25 and provides the user with the results that were being 
sought by the user without attention to the languag 
of the program(s) in and loaded into the computer. 

In telecommunication networks with electronic 
switching, the switching system or systems plays the 

30 dominant rofe in executing the various steps that ar 
necessary for call processing. The sequence of the 
steps necessary for the completion of call processing 
is much more varied than the sequence of instruc- 
tions for data processing. The switching systems may 

35 be distributed and the cooperative role of the various 
switching systems may become essential. This as- 
pect is not unlike the controlled distribution of th 
processing in multiprocessor/multicomputer systems. 
Fortunately, with the evolution of the common chan- 

40 nel interoffice signalling system and the standardiza- 
tion of its protocol, distributed call processing is not a 
problem in most modern communication networks. It 
is interesting to note that the level of programming in 
the switching systems is at higher level than the pro- 

45 gramming level of the third generation programming 
languages. This jump leaves the programmers of the 
switching systems with the more mundane functions 
of 7enerating the executable code for the normal 
three modules (communication, switching, and ad- 

50 ministrative) of the switching system. 

In modern "intelligent" networks (such is used by 
the Assignee herein. AT&T Corp.. as well as other Uni- 
versal Intelligent Networks), the service provisioning 
of the special services becomes the cooperative role 

55 of at least five well known interdependent computer- 
ized systems. These interdependent computerized 
systems are the service switching points, the service 
transfer points, the service control points, the service 

2 
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creation environment and intelligent peripherals. 

Some of these known systems are substantially 
modified and/or supplemented in the present Inven- 
tion to create a unique integrated medical computer 
system environment These significant changes are 
neither taught nor rendered obvious by the prior art 

SUMMARY OF THE INVENTION 

The present Invention involves a hospital-based 
integrated medical computer system for processing 
medical and patient information and for evolving med- 
ical knowledge, diagnoses and prognoses. It includes 
at least one processor including a memory and a plur- 
ality of medical data banks connected thereto, and a 
plurality of separate processor hardware modules at 
least indirectly connected to the memory. The mod- 
ules include a communication module, at least one 
switching module, an administrative module and a 
knowledge base module. There is also hardware, 
firmware and software in the processor hardware 
modules to enable the modules to perform at least the 
following functions: for the communication module, to 
control all functional processes of the other modules, 
the main memory and the processor, so that they ef- 
fectively communicate with one another; for the 
switching module(s), to select and switch between se- 
lected information as it becomes relevant to a process 
of solving a particular problem; for the administrative 
module, to perform housekeeping functions, includ- 
ing multitasking control with resource allocation, real- 
time multitasking and scheduling of tasks; and, for the 
knowledge base module, to operate knowledge proc- 
essing functions and to store information in the med- 
ical data banks. In preferred embodiments, there are 
general patient databases, physician access point 
units, patient access point units, and service facili- 
ties. In other embodiments, a plurality of processors 
are included with their own memories and modules 
and are linked together to establish a processor unit. 
In processor net embodiments, there may be one or 
more separate integrated services digital networks 
dedicated to predetermined medical related func- 
tions. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is more fully understood 
when the specification herein is taken in conjunction 
with the drawings appended hereto, wherein: 

Figure 1 illustrates a schematic diagram of a 
present invention integrated medical computer 
system hospital-based medical processor unit 
with six buses for monitoring the flow of informa- 
tion in a large medical complex; 
Figure 2 illustrates one embodiment of a present 
invention network based integrated medical com- 
puter system which has a plurality of processors. 



switching modules and knowledge base mod- 
ules; and. 

Figure 3 illustrates a simplified version of a pres- 
ent invention integrated medical computer sys- 
5 tem with limited functionality for a single input, 

single output and single user for system. 

DETAILED DESCRIPTION OF THE INVENTION 

10 I. Introduction 

In the present invention integrated medical sys- 
tem, the processing is based upon the methodology 
fundamental to any problem solving. A problem is 

15 identified from the data at hand, additional search 
and confirmation is sought based upon a partial hy- 
pothesis or a hunch (intuitive pattern match). When 
a certain level of confidence is achieved, the existing 
knowledge banks are queried about categorizing the 

20 problem at hand. If the data is insufficient, an addi- 
tional search is conducted to gain additional confir- 
mation/denial of the partial hypothesis. Under condi- 
tions of certainty in the cause-effect relationship, few- 
er searches lead to the required confidence level be- 

25 fore the solution is initiated. Under uncertainty or fear 
of persecution, more confirmation and consultation is 
sought regarding categorization, verifying the exist- 
ing knowledge banks, and then the eventual solution 
to the problem accrues. 

30 In the real world, these steps are iterated many 

times over, especially if there are numerous inter- 
twined problems, numerous cause-effect relation- 
ships, and numerous remedies. Lack of complete in- 
put data causes additional uncertainty. Whereas ev- 

35 ery patient is unique in his/her own right, there is 
enough science and logic embedded in the profession 
that computers and networks can handle the various 
steps in the solution to the problem quickly, system- 
atically, and within any given percentage of confi- 

40 dence. Apart from steps in the remedy and cure, the 
present invention integrated medical system may also 
handle more mundane aspects of accounting, patient 
history tracking, resource allocation, scheduling, re- 
cord keeping, and security of infonmation. Follow-up 

45 procedures can also be made thorough and conv 
plete. The architecture is flexible to permit the inte- 
grated medical system to function in any type of a 
medical facility ranging from a dispensary to a com- 
plete hospital and health care complex. 

50 The methodology upon which the integrated 

medical system functions is by partitioning the proce- 
dural steps in their modular microscopic or macro- 
scopic forms. Logical relations between these steps 
permit their programming. Weak logical relations de- 

55 mand more intricate programs invoking additional 
searches or knowledge-based functions. Weak logic, 
coupled with uncertainty, reduced the confidence to 
an extent that the integrated medical system turns the 
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problem to a group of on-line physicians. 

One situation where human intervention is usu- 
ally not needed is the communication network. Calls 
from the subscribers are routinely processed by tele- 
communication networks and special service orient- 
ed calls are processed by intelligent networks. These 
networks systematically reduce the switching, trans- 
mission, and administration functions of "call proc- 
essing" in a series of machine executable subfunc- 
tions and are completed in an orderly way depending 
upon the outcome of the previous process. The call is 
initiated, processed, monitored, and completed over 
the duration of the call. This may take several sec- 
onds (voice calls) to several months (dedicated lines) 
or even a life-time (700 numbers operations) depend- 
ing upon the service required. In this situation, deal- 
ing with communication networks, the deeper insight 
and the superior perception of the human is not nec- 
essary for the "call-processes" which in the decade of 
nineties are well streamlined and optimally program- 
med. 

One situation where the human intervention is 
constantly needed is the maneuvering of an airplane 
or a spacecraft. In this case, the input conditions are 
so various that the human intelligence is likely to pro- 
duce significantly improved results. In addition, the 
cost of failure is very high. The invocation of human 
insight and perception greatly influences the output 
and reduces the probability of fatal errors. 

In the case of the present invention integrated 
medical computer system, the parameters lie in a 
range somewhere between the two extreme exam- 
ples given above. At the two extreme blends of man- 
machine team, the environment may be adjusted suf- 
ficiently to generate an all-man-no-machine hospital 
or an all-robot-no-man hospital. Through the present 
invention integrated medical computer system, the 
less expensive mechanized computer systems can 
take over some of the functions performed by the 
more expensive physician teams, thus generating 
more economical and optimal medical environments 
in countries where physicians and their administra- 
tors are expensive. 

II. Processor Environments in Integrated 
Medical System 

In the present invention system, the architecture 
of the control processing unit of any moderate speed 
computer is modified with enhanced memory capa- 
bilities to process the medical procedures for pa- 
tients. The enhanced memory will hold executable 
programs for the patient in the special hospital, med- 
ical center, or even the country in which the proce- 
dure is going to be performed. These subprocedures 
will be intelligently assembled based upon the artifi- 
cial intelligence oriented knowledge bases. For this 
reason the high level language software (the compil- 



er-assembler-loader-linker software chain) of the in- 
tegrated medical system to be significantly different 
from that of th traditional computer systems. Thus, 
the set of assembly level procedural instructions will 

5 be tailored to the specific medical facility, thus calling 
for a facilities dependent assembler. This type of 
adaptation is routinely made for computer systems at 
installation time depending upon the hardware in that 
particular system. It is also done for the switching sys- 

10 terns when any software controlled switch (e.g. elec- 
tronic switching system facility) for any telecommuni- 
cation system is installed. 

The dependability concern in present invention 
systems may be handled by dual processors and 

15 elaborate error checking. The error checks not only 
verify the processing, but also the validity of the re- 
sults based upon the artificial intelligence based ex- 
pected outcome. Any unexpected findings are refer- 
red to the physician team on duty. Results of proce- 

20 dures will be entered into a patient database. Opin- 
ions and subjective comments will be entered onto a 
voice activated message retrieval system. Pictures, 
X-rays, and CATSCANs may be entered onto a visual 
database of the computer system, making the inte- 

25 grated medical system a truly multi-media system. 

III. Medical Computer Architecture 
3.1 The Medical Processor Unit 

30 

Traditional control processing unit architectures 
entailing the control unit, the arithmetic unit, the logic 
unit, the control memory, interrelated with single or 
multi bus structures simply do not suffice for the pres- 

35 ent invention medical applications. In the present in- 
vention, medical processor unit does not process 
data. It only generates a sequence of subprocedures 
for current or standard medical procedures consistent 
with the patient history, physician's - expert system 

40 capability/expertise, and capability of the medical fa- 
cilities available in that particular environment. 

The typical operator-operand function of the 
medical processor unit of the present invention is nei- 
ther traditionally binary nor hexadecimal; instead It is 

45 based on a combination of factors, such as the knowl- 
edge of the patient (available in the patient database), 
and the experience of the medical team, in a general 
categorical sense and with reference to that particular 
patient. Both of these are dynamic and can vary sig- 

50 nif icantly. For this reason, expert and knowledge sys- 
tem-based programs are used and used consistent 
with the capability of the particular medical facilities 
which will be utilizing the present invention system. 
The microprograms in the medical processor unit 

55 will function in three independent fashions initially 
and then in an interdependent fashion subsequently. 
First, any approved expert system database is refer- 
red for current concepts and breakthroughs. Second, 
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the practice of the particular physician and the med- 
ical facility Is referred to in order to be consistent with 
the knowledge level of the physician and the nnedical 
facility. Third, experience of this physician and earlier 
physicians with this particular patient is referred. All 5 
the necessary checks and verifications are nnade be- 
fore administering any particular procedure to any 
particular patient in view of the patient history. 

The output of the present invention system med- 
ical processor unit is a series of instructions based io 
upon the opinion of the current experts approved by 
a team of physicians (if necessary) which has been 
verified for processing and expectation by dual inde- 
pendent processors. The output of the processor is a 
series of subprocedures which will be dispatched to 15 
the actual medical facilities after appropriate alloca- 
tion of existing medical resources to the patient's sub- 
procedures. Scheduling, resource sharing, time and 
priority allocation will be done automatically depend- 
ing on the time or code of service being performed 20 
(emergency, standard, diagnostic, routine, etc.). This 
system is accountable for every step of its function 
and no tampering of any sort Is possible by encryption 
of subprocedural code and patient data. The decryp- 
tor key and its code identification is available to the 25 
medical staff. Such measures of additional safety and 
streamlined handling of the procedures can make the 
overall service provisioning current, economic, and 
accountable at every subprocedural step. 

30 

3.2 Subprocedure Instructions 

From preliminary considerations, these may be 
numerous broadly definable instructions. Three such 
categories are knowledge based inferential instruc- 35 
tions, search instructions, and administrative or local 
housekeeping instructions. 

In the first category, the knowledge structure of 
the cause-effect relation is queried, or the logical pre- 
dictable effect is being sought, or conversely the pre- 40 
conditions for a given state is being investigated. It is 
important to note that certainty is never the strong 
point of this type of processing. Every step is prone 
to a confidence level. Thus the chain of subproce- 
dures which make up a given procedure is the product 45 
of such individual confidence levels. Fuzzy-set Infor- 
mation processing is most appropriate for the execu- 
tion for this category of instructions. 

In the second category, the search is being initi- 
ated. Two groups emerge as fallows. The first group so 
deals with search in the knowledge (professional, 
medical opinion, possible cures, diagnostics, etc.) do- 
main and the second group deals with search in the 
data (files, patient information, databases, insurance 
company codes, service providers, drug vendors, 55 
etc.) domain. 

In the first group, the input is the incomplete input 
data to investigate which other twigs of the knowl- 



edge tree are logically associated with the given in- 
puts. Forward and backward pointers may be sought 
by this type of instruction. Similar symptomatic con- 
ditions may be queried. Associative and forward 
searches may be initiated by this type of instruction. 
The first category and second set of instructions are 
not always orthogonal and involving the first set can 
also invoke the second set and vice versa. Recursive 
searches should then be possible to/from and within 
the knowledge domain linking the objects in the data 
domain. 

In the second group, the input is complete for the 
data processing units to offer complete and definite 
response. Example of this type of search is the social 
security number of a patient or the last visit to the hos- 
pital. Definite and precise answers are sought and se- 
cured from the present invention integrated medical 
system. By separating the searches in two groups, 
the instruction sets to the integrated medical system 
can be separated as (a) searches dealing with the 
knowledge domain or (b) searches dealing with the 
data domain. The hardware, software, firmware, and 
peopleware domains responsible for the execution of 
these two types of searches may thus be isolated and 
optimized. 

In the third category, the administrative functions 
of the local medical facility may be activated. Typical 
of such instructions are scheduling of operating 
rooms, issuance of the hospital beds, allocation and 
consistency of the physician teams, accounting and 
billing, updating of the patient databases, etc. This 
category of instruction is localized to the environment 
of the medical facilities, the personnel, the support 
staff, and the type of services it is expected to pro- 
vide. It is suggested that the input/output bus for this 
category of instruction be isolated from the input/out- 
put bus for the other two types of instruction to avoid 
any possible contamination of information to and from 
the established knowledge bases. Standard techni- 
ques for the construction, maintenance, and use of 
such knowledge bases are available. 

3.3 Speed and Capacity of the Medical 
Processor Unit 

From the point of view of implementation, the 
speed of the medical processor unit is not crucial, ex- 
cept when the physician prefers a real-time look up of 
how the medical processor unit would handle a cer- 
tain situation. For this reason we foresee two types 
of medical processor units. The first type of medical 
processor unit handles the batch type of job process- 
ing and the second type handles the on-line process- 
ing. The architecture of the two systems thus differs. 
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3.3.1 Remote M dical Pr cessor Units (Job 
Processing Environments) 

Under normal conditions any particular patient's 
identification may be submitted to the medical proc- 
essor unit with a desired procedure or even a com- 
plaint or symptom and the primary medical/vital data 
of the patient (e.g.. temperature, blood pressure, 
heart rate, etc. as the paramedical teams dispatch to 
the physician). The non real-time response will be 
generated and mailed {dispatched electronically) to 
the doctor. Under the latter conditions, the memory 
and database capability of the medical processor unit 
to act in conjunction with the artificial intelligence 
based programs becomes the key element. Typically, 
in remote medical processor unifs, the memory size 
and database capability can be compromised for 
speed. Dual independent processing (as it is done in 
most electronic switching system facilities) can only 
double the cost of high capacity low-speed machine. 
Job priorities are assignable to the patient and proce- 
dures. Procedure sequences are forced in subse- 
quent time slots and time and resource sharing can 
thus be optimized. 

Almost all remote medical processor units need 
to be network based since the medical knowledge 
bases can also be remote and one medical processor 
unit can service many hundreds of remote input loca- 
tions. The searches performed by remote medical 
processor units can become more thorough and wide 
in non real-time applications. 

3.3.2 Hospital Based Medical Processor Units 
(On-line Processing) 

When real-time response is necessary for the 
medical processor unit, architecture can be readjust- 
ed for speed and response rather than extensive 
searches for a large number of patients and subscrib- 
ers. When certain procedures are necessary quickly, 
cost of service provisioning, and economics of provid- 
ing services from various hospitals, laboratories, di- 
agnostic services, or even doctors may be sacrificed 
for urgency. However, under normal conditions, the 
patient can be provided with the most cost effective 
strategy for the services to be perfonned. Specialized 
service providers will effectively use alt their resourc- 
es optimally and marginal service providers will get 
phased out. 

3.3.3 Processor Speed, Confidence level and 
Patient Load 

The most time consuming task of the processor 
is the search through numerous knowledge bases to 
achieve a high confidence in the inference it draws 
about the next logical step or the next inferential step. 
One can defeat the integrated medical system by in- 



sisting upon a 100 percent confidence with insuffi- 
cient input data with exhaustive knowledge bases or 
conversely with sufficient input data but with inade- 
quate knowledge bases. To be realistic about the re- 

5 suits that the integrated medical system can gener- 
ate, a compromise in what is being queried is essen- 
tial. Being a programmed system, it can provide only 
inferential results with varying degrees of confi- 
dence. Exhaustive searches take a longer response 

10 time as do the peak-hour high-patient-load queries. 
Here the processor speed provides a compromise. 
Expensive high speed systems can yield high confi- 
dence inferences at the busiest hospital hours and 
vice versa. Smaller medical facilities will thus need a 

15 lower power processor. Job scheduling algorithms by 
the operating system (as they are used in traditional 
computer systems) wilt prove useful in generating an 
acceptable response time from the integrated medi- 
cal system. 

20 Other tasks such as patient scheduling, shared 

resource allocation, sequentiality of subprocedures, 
minimum hospital stay requirements, etc. are rela- 
tively trivial for the integrated medical system. 

25 IV. Architectural Considerations 

4.1 Processor-Based Local-knowledge-Bank 
System 

30 Figure 1 shows a processor-based local knowl- 

edge bank integrated medical computer system 1. 
Here, the processor 3 and knowledge banks are in 
close proximity such that bus lines can be extended 
from processors to these knowledge banks (medical 

35 data banks 5, 7 and 9). The addressing is done via 
bus-selector through bus 11 tied to a particular knowl- 
edge bank. The address of the bus may be consistent 
with the classification of the information stored in that 
particular bank thus reducing the seek time in thes 

40 massive information stores. In such systems, the in- 
struction to the knowledge bank is followed by a burst 
of input data via a direct memory access channel. 
Note that the contact between the patients and the 
physicians may be in real-time, or via remote access. 

45 Considerable latitude exists in the design of the 

memory, processor, and the bus structures. At one 
extreme, we have the knowledge banks bursting their 
entire segments of all the relevant information back 
to the main memory of the medical processor 3 where 

50 the instruction is executed. At the other extreme, we 
have a complete instruction being dispatched by the 
medical processor 3 to the knowledge banks and the 
knowledge banks, e.g., in their own local processors 
execute instructions or part thereof. The partial result 

55 (in a shorter burst) of the instruction is dispatched 
back to the medical processor 3. 

This aspect of the processing is novel over the 
conventional computing environments where part of 
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the execution of the instruction takes place in the 
memory. Sonne of the sophisticated database soft- 
ware packages can perform these functions for the 
integrated m dica! system. The compromises in the 
cost and performance are evident from the two hard- 
ware configurations. 

Every subprocedure is thus executed and the net 
result of the procedure Is conveyed to the user (or the 
user program). The output is generated from subpro- 
cedures, procedures, runs, and entire usage of the in- 
tegrated medical system in an orderly and systematic 
fashion. Debugging of the integrated medical system 
functions becomes as easy as reading the registers 
and core dump of the medical processor unit or the 
registers and the core dump of the local processing 
units of the knowledge banks. 

The processor 3 includes a memory and an ad- 
ministrative module 13, a knowledge module 15. a 
communications module 17 and switching modules 
19. 21 and 23. In addition to the knowledge bus 11, 
there is a patient bus 25 connected to general patient 
database 27, a procedure/lab bus 29 connected to a 
procedure/result analysis 31. Output bus 33 is con- 
nected to services facilities 35, which may, for exam- 
ple, include tissue work 37, therapy 39, blood work 
41, imaging 43, and others (etc.) 45, such as. for ex- 
ample, urinalysis. 

Processor 3 is also connected to a plurality of pa- 
tient access point units 47, 49 and 51 via input bus 53. 
These units can include individual patient medical 
bases 55, 57 and 59 and can include input to proces- 
sor 3 as well as output from processor 3. These units 
could monitor patient's conditions, input data, provide 
instruction to the patient and track patient conditions 
and alert the hospital staff and/or physician(s) to such 
changes. 

There may also be connected to processor 3 a 
plurality of physician access point units 61 , 63 and 65. 
via physicians bus 67. Though these units physicians 
may access services facilities 35, procedure/result 
analysis 31, any or all medical data banks 5. 7 and 9. 
general patient database 27 and patient accesspoint 
units 47. 49 and 51. The physicians may do so 
through processor 3 as a direct user via such buses 
described above, or indirectly by query to the proces- 
sor 3, whereby the processor 3 will utilize whatever 
modules, memory, programs, subprograms, buses 
and connected units and facilities as may be neces- 
sary or appropriate to respond to particular queries 
posed by the physician user. 

4.2 Distributed-Knowledge-Sank System 

In this type of present invention system 101 
shown in Figure 2, many medical processor units e.g. 
units 103, 105 and 107 and knowledge banks 109. 
Ill and 113 are linked via a high speed integrated 
services digital network 115. Isolated packets of in- 



formation arrive at the knowledge banks from numer- 
ous integrated medical systems connected therewith. 
Thus, the collection of numerous units, such as units 
103, 105 and 107 form a processor net 200. Optimal 

5 protocol design and packet structure is a matter of 
design by the artisan now that this environment has 
been defined. For example, the addressing of the dis- 
tant knowledge banks is done via a subject matter 
identifier allocated to the distant knowledge bank. 

10 This identifier of the knowledge bank is consistent 
with the information stored in that particular bank thus 
reducing the switching time to these massive informa- 
tion stores. In such systems, the instruction to the 
knowledge bank is followed by a burst of input data via 

15 the packet switching network located within proces- 
sor net 200. (It should be assumed that processor net 
200 contains individual processors similar to proces- 
sor 3 of Figure 1 with the memory and various mod- 
ules as described therein.) 

20 Every subprocedure is thus executed via an indi- 

vidual packet command (like the modern signalling 
system, packet commands or subprocesses in the 
back-bone network are embedded in the intelligent 
networks). The net result of the procedure is con- 

25 veyed to the user (or the user program) by a series of 
packet transactions. Such transactions between a 
single integrated medical system and multiple knowl- 
edge banks are systematically processed and the 
output is accumulated from subprocedures. proce- 

30 dures and runs. The entire usage of this present in- 
vention network based integrated medical system is 
as orderly and systematic as job processing in distrib- 
uted computer environments. 

Referring again to Figure 2, the integrated medi- 

35 cal system 101 may not only include integrated ser- 
vices digital network 1 1 5 for connection to knowledg 
banks (medical data banks), but may have a plurality 
of integrated services digital networks for various pre- 
determined functions. Thus, integrated services dig- 

40 ital network 123 is connected from net 200 to patient 
access point units 117, 119 and 121; integrated ser- 
vices digital network 129 is connected from proces- 
sor net 200 to physician access point units 123, 125 
and 127, Likewise, net 200 is connected to general 

45 patient databases, such as infectious diseases 131, 
chronic illnesses 133 and active ailments 135, via in- 
tegrated services digital network 137; is connected to 
drug and device vendor net 139 via integrated servic- 
es digital network 1 41 ; and is connected to service fa- 

50 cilities net functions such as blood, tissue and neu- 
rology 143. imagining scans 145 and other functions 
147, via integrated services digital network 149. 

Debugging of these types of integrated medical 
system functions becomes as easy as studying the 

55 packet contents of any given procedure. 
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V. Input/Output Considerations 

5.1 Input Aspects 

Compared to conventional computer systenn/net- 
works. the input/output interface parameters can be 
highly variable for any of the present invention sys- 
tems. Streamlining the human and verbal communi- 
cation may be somewhat effective to accelerate input, 
but perfection is Impossible. For this reason, it is pro- 
posed that, in preferred embodiments, the input to 
present integrated medical systems be via laser or 
otherwise encoded credit-card-sized medical identi- 
fication for routine cases (or a sequence of cards for 
extremely acute cases). A short data structure of vital 
statistics, chronic conditions, allergies, blood type, 
genetic predispositions, etc. may be encoded on this 
card with a forward pointer to where (i.e., patient da- 
tabase location) all of the patient history is stored. The 
input processors may be located like credit card cen- 
ters or automatic bank teller machines throughout the 
population centers tied to the integrated medical sys- 
tem. 

It is desirable to have a progression of such med- 
ical card centers ranging from most rudimentary to 
sophisticated medical centers. Typical examples of 
the rudimentary facilities are those for dispensing 
routine medication (like insulin or hypertension med- 
ication, or birth control pills, etc.) from integrated 
medical system controlled medication warehouses. It 
is expected that the integrated medical system will 
make an appointment for the patient every so often 
after the programmed sequence of refills is complete 
and direct the patient to go to next hierarchical med- 
ical card center. 

Typical of the next hierarchical medical card cen- 
ter is one equipped with other monitoring devices 
(such as those for reading the temperature, blood 
pressure, throat scanners, EKG recorders, imaging 
centers, etc). It is also expected that the most recent 
patient input is entered into the patient database via 
the integrated medical system. Whereas the higher 
level centers can perform the functions of the lower 
level centers, they still act as a check point to the ac- 
cess of the highest levels of the medical card centers. 

At the highest level of the input processors exist 
the current staffed hospitals, therapy centers, deliv- 
ery rooms, operating theaters, intensive care facili- 
ties, etc. The situations requiring the services of 
these facilities typically defy the programmability of 
the next step. However, since the integrated medical 
system is networked to service all medical card cen- 
ters, access and referral throughout card centers on 
the network is automatic. 

5,2 Output Asp cts 

The output from the integrated medical system 



can also have significant variations. Ranging from no 
action to immediate hospitalization or surgery, the in- 
tegrated medical system reaches all medical service 
facilities such as drug dispensing machines, physical 
5 therapy centers, blood banks, nursing homes, and the 
higher levels of the medical card centers listed in Sec. 
5.1. 

One of the possible ways of handling the outputs 
of the integrated medical system is via specialized 

10 nodes created on the network. Similar to the knowl- 
edge processing where nodes are addressed by the 
subject matter they hold, the output nodes are ad- 
dressed by the type of service that is scheduled 
through them. For example, if the architecture is 

15 equipped via a node for physical therapy all requests 
for this service would go through this node. The geo- 
graphical dispersion of the patients and services cen- 
ter is tackled by mapping the zip codes of the patient 
and of the service provider. One example where such 

20 service is already provided Is by matching the real es- 
tate agent with clients moving into a new area. 

5.3 Overall Input/Output Design 

25 If the medical processor unit is considered as a 

single entity, it is logical in many environments to iso- 
late the input and the output bus of the medical proc- 
essor. System dependability is greatly enhanced. 
Since the integrated medical system is generally net- 

30 work based, the separation of the input and output 
ports on all the medical processor units in the net- 
work would be desirable to reduce any risk of mal- 
function or logical processing the inputs and coordin- 
ating the corresponding outputs. 

35 If the argument for the separation of the input and 

the output ports is taken one step forward, then it is 
easy to see the input/output architecture of any med- 
ical processor unit. Inputs from numerous medical 
card centers will follow the input path to most logically 

40 accessible medical processor unit via the type of 
medical service request. If certain medical processor 
units can handle specialized services (depending 
upon the contents of its own knowledge banks), then 
the logical address of the medical processor unit is 

45 determined by the network by mapping the service 
request for the patient with the service capability the 
medical processor unit is specially capable for han- 
dling. The type of hierarchical addressing reduces the 
complexity of the look-up tables for the particular 

50 medical processor unit and the service provider for 
any service request for any patient. 

The specialization of the medical control units, 
and that of the service providers in by itself thus pro- 
vides the logical addressing of these nodes in the in- 

55 tegrated medical unit. It is expected that if the inte- 
grated medical system architecture is designed 
based upon the separation of specialty, then the sep- 
aration of the input and output ports of the individual 
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medical control units, then the flow of information can 
be significantly streamlined thus reducing the prob- 
ability of any possible errors in processing the medi- 
cal information for any particular patient. 

VI. Implementational Considerations 

At first level the integrated medical system 301 
may be fabricated by a two (or a network) of general 
purpose computers (see Figure 3) with one knowl- 
edge machine 201 acting as the execution unit of the 
knowledge-based subprocedural instructions such 
as the processor 3 of Figure 1 , or a subset of the func- 
tions of processor 3 of Figure 1. (Reference is made 
to the first and second categories of instructions in 
Sec. 3.2 above). At the most rudimentary level of soft- 
ware, standard packages such as MYCIN or INTERN 
may be used in the knowledge machine 201. 

Any special hardware or system, functioning as a 
database machine 311 holds at least a subset of the 
medical knowledge for a subspecialty. Access to pa- 
tient databases 313 and 315, MYCIN databases 317 
and 319 and hospital resource databases 321 and 
323 would be a reasonable first level connection. The 
language and user interface input 303 can be made 
keyboard or mouse^driven. The output 305 can be 
made displayed on rudimentary graphic displays. A 
single user system greatly reduces the need for any 
sophisticated or expensive hardware. 

The housekeeping functions may also handled 
by one general purpose computer hardware unit with- 
in the knowledge machine 307 with a special software 
for resource (computer and medical) allocation, billing 
and patient record keeping. This is typical of a very 
small computer system specifically tailored for any 
given application. 

With some initial software organization and de- 
bugging, these rudimentary medical systems can be- 
come functional in a very short time. For the implen- 
tation of large integrated medical systems, special- 
ized software deployment strategy will become es- 
sential for optimal performance, and to this extent the 
design of the integrated medical system is the similar 
to the design and deployment of any other large scale 
special purpose computer system with dominant com- 
ponent of knowledge processing and database capa- 
bility. National and network access may be and pre- 
ferably will be provided by the new communication 
protocol embedded in any intelligent network or even 
the upcoming integrated services digital network. 

VII, Machine/Network Failure and other 
Catastrophic Events 

The probability of catastrophic failure is finite, 
even though it can be made less than any given small- 
est number by robust design. It is not our contention 
that such an event will not occur, instead we assert 



that certain routine precautionary steps in running 
and maintaining the integrated medical system can 
significantly reduce the collapse of the integrated 
medical system. 

5 Some of these steps are similar to those taken by 

the Regional Bell Operating Companies in maintain- 
ing and safeguarding the Service Control Point data- 
base. Banks and computer systems routinely archive 
their information. Diagnostics are run frequently. Crit- 

10 ical information is retained at more than one place. 
Constant copy and verify statements are executed in 
the system to monitor the accuracy and authenticity. 
Critical steps are run twice for confirmation. Incre- 
mental change of stored information is rechecked for 

15 accuracy and rationale. Dual processors are used to 
validate the processor functions. Error checking and 
correction is maintained in all transmission. Encryp- 
tion is used to prevent tampering. Physician and tech- 
nician code are checked for authorization to modify or 

20 alter the medical records before any change is ac- 
cepted. 

Precautionary measures are based upon the 
possible reasons and sources of errors. In large, com- 
puter systems security issues have been tackled to 

25 make them less error prone. In the two architectures 
suggested, only the modules which do interact are in- 
terconnected. Logical and access (by txDth hardwar 
and software techniques) denial block contamination 
of information due to processor or software error or 

30 to some extent the hardware malfunction. The archi- 
tectures proposed permit some capacity to identify 
and isolate errors and the modules in which they start. 
The system monitors these conditions before a cata- 
strophic mishappening by blocking erroneous hard- 

35 ware from its communication capability. 

Present invention integrated medical computer 
systems are likely to foster over- dependability upon 
itself. Vigilance may sometimes be lost and peopi 
may tend to become addicted to the integrated med- 

40 ical system capability and power These issues may 
persist in any situation where new systems are intro- 
duced. Corporations may become addicted to their 
management information systems, banks can not 
function without the network response, stock mar- 

45 kets can not transact when the network is down, and 
so on. Transition to integrated medical system is likely 
to meet a considerable negativism like management 
information system has met in corporations and ro- 
botics has met in mass production. However, not to 

50 bring the true capabilities of computers, networks 
and artificial intelligence techniques to medicine ap- 
pears to be like withholding calculators from schools. 

VII. Conclusions 

55 

Numerous versions of the present invention inte- 
grated medical computer systems have been present- 
ed. The classification of subject matter and the de- 
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sign of modular software oriented to the performance 
of medical subprocedures becomes essential. Coor- 
dination of these medical subprocedures with the ex- 
pertise of the medical staff and the use and availabil- 
ity of medical facilities in the hospital or the medical 5 
center becomes a crucial step in the deployment of 
the integrated medical system in practice. 

The separation of the input and output processing 
at the nodes of the medical processor units in the net- 
work is desirable to streamline the multitude of input- io 
output transactions at any integrated medical system 
node. The hierarchical separation based upon the 
specialization of the medical processors makes net- 
work addressing of these nodes flexible and straight 
forward. Additional nodes may be added or removed ts 
from the integrated medical system. The hierarchical 
separation based upon the services provided by the 
service providers also makes the network addressing 
of these vendors flexible, straight-forward and pro- 
grammable. Such vendors may be added or deleted 20 
from the integrated medical system to offer most op- 
timal and economical service by the integrated med- 
ical system. 

This approach is feasible in light of the recent de- 
velopments in database storage and access technol- 25 
ogy (for the hierarchical organization of medical infor- 
mation, its real-time access, and associative search- 
s). Artificial intelligence techniques (for knowledge 
processing such as forward/backward linking, induc- 
tive and predictive logic, pattern recognition, expert 30 
system consultation capability), and specialized op- 
erating systems (for resource management, alloca- 
tion, conflict and dead-lock resolution, accounting, 
billing and record keeping). With the cooperative role 
of the interdisciplinary team of systems designers, in- 35 
tegrated medical system can be as useful to the 
health industry as the airplanes are to the transpor- 
tation industry or as computers are to the scientific 
community. 

Obviously, numerous modifications and varia- 40 
tions of the present invention are possible in light of 
the above teachings. It is therefore understood that 
within the scope of the appended claims, the inven- 
tion may be practiced otherwise than as specifically 
described herein. 45 



Claims 



2. 



3. 



ing a cornmunication module, at least one 

switching module, an administrative module 

and a knowledge base module; 

(b) hardware, firmwar and software in said 

processor hardware modules to enable the 

modules to perform at least the following 

functions: 

(i) for the communication module, to control 
all functional processes of the other modules, 
the main memory and said at least one proc- 
essor, so that they effectively communicate 
with one another 

(ii) for said at least one switching module, to 
select and switch between selected informa- 
tion as it becomes relevant to a process of 
solving a particular problem; 

(iii) for the administrative module, to perform 
housekeeping functions, including multitask- 
ing control with resource allocation, real-time 
multitasking and scheduling of tasks; and, 

(iv) for the knowledge base module, to oper- 
ate knowledge processing functions and to 
store information in said medical data banks. 

The hospital-based integrated medical computer 
system of claim 1 wherein said system further in- 
cludes a general patient database connected to 
at least one of said memory and said processor 
hardware modules. 

The hospital-based integrated medical computer 
system of claim 1 wherein said system further in- 
cludes a plurality of physician-based, remotely lo- 
cated physician access point units connected to 
said processor for operating said system from re- 
mote sources. 

The hospital-based integrated medical comput r 
system of claim 1 wherein said medical data 
banks include a plurality of subareas of knowl- 
edge, and said knowledge base module includes 
a plurality of subprocesses, and said communica- 
tion module has software to further control com- 
munication between the subareas of the medical 
data banks and the knowledge base module and 
to control the subprocesses as they pertain to a 
particular medical problem and to systematically 
organize inputs and outputs of the subprocesses. 



1, A hospital-based integrated medical computer 50 
system for processing medical and patient infor- 
mation and for evolving medical knowledge, diag- 
noses and prognoses which comprises: 

(a) at least one processor, including a memory 
and a plurality of medical data banks connect- 55 
ed thereto, and a plurality of separate proces- 
sor hardware modules at least indirectly con- 
nected to said memory, said modules includ- 



The hospital-based integrated medical computer 
system of claim 1 wherein said system further in- 
cludes a plurality of remotely located patient ac- 
cess point units connected to said processor for 
operating said system from remote sources by 
patients for predetermined purposes. 

A method of operating a hospital-based integrat- 
ed medical computer system for processing med- 



io 
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ical and patient information and for evolving med- data banks towards solving a particular medical 

ical knowledge, diagnoses and prognoses which query in a perceptive manner. 

comprises: 

(a) operating at least one processor, which in- 
cludes a memory and a plurality of medical 5 
data banks connected thereto, and a plurality 

of separate processor hardware modules at 
least indirectly connected to said memory, 
said modules including a communication 
module, at least one switching module, an ad- io 
ministrative module and a knowledge base 
module; 

(b) operating hardware, fimnware and soft- 
ware in said processor hardware modules to 
perform at least the following functions: is 

(i) for the communication module, controlling 
all functional processes of the other modules, 
the main memory and said at least one proc- 
essor, so that they effectively communicate 

with one another; 20 

(ii) for said at least one switching module, se- 
lecting and switching between selected infor- 
mation as it becomes relevant to a process of 
solving a particular problem; 

(iii) for the administrative module, performing 25 
housekeeping functions. Including multitask- 
ing control with resource allocation, real-time 
multitasking and scheduling of tasks; and, 

(tv) for the knowledge base module, operating 
knowledge processing functions and to store 30 
information In said medical data banks. 

7. The method of claim 6 wherein said system fur- 
ther includes a general patient database connect- 
ed to at least one of said memory and said proc- 3S 
essor hardware modules. 

8. The method of claim 6 wherein said system fur- 
ther includes a plurality of physician- based, re- 
motely located physician access point units con- 40 
nected to said processor for operating said sys- 
tem from remote sources. 

9. The method of claim 6 wherein said medical data 
banks include a plurality of subareas of knowl- 45 
edge, and said knowledge base module includes 

a plurality of subprocesses. and said communica- 
tion module has software to further control com- 
munication between the subareas of the medical 
data banks and the knowledge base module and so 
to control the subprocesses as they pertain to a 
particular medical problem and to systematically 
organize inputs and outputs of the subprocesses. 

10. The method of claim 9 wherein the software for ss 
the communication module Includes the ability to 
select and collate subprocesses of the knowl- 
edge base module and the data from the medical 

11 
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FIG. 3 



313 



317 



319 



311 



321 




^^SL/ DATABASE 
' MACHINE 



GENERAL PURPOSE 
COMPUTER SYSTEM 
NHICH CAN ALSO 
SERVE AS A 
KN0NLE06E 
MACHINE 



OUTPUT 



307 



•305 



14 



BNSDCCID: <EP 065252eA2.l.> 



